In general, transaction processing in a main memory-based database management system (DBMS) occurs with significantly faster performance than in disk-based DBMS. This improvement can be realized at least in part through retention of data in main memory, which reduces the need for read/write operations to move data between main memory and persistent storage (e.g. hard drives, solid state drives, optical drives, magnetic drives, etc.) for execution of various databases functions (e.g. table joins, queries, reads, writes, deletions, etc.). Transaction processing in disk-based DBMS can generally consume significant execution time waiting for completing disk input and output (I/O) operations. In contrast, in a main memory-based DBMS (e.g. an “in-memory” database management system), resolution of conflicts between transactions and waiting for completion of disk I/O occurs fairly rarely. As a consequence, context switching overhead for resolving conflicts is greatly reduced in main memory-based DBMS, which can also offer faster response and higher performance of transaction processing.
Ensuring reliability in a disk-based DBMS is typically achieved by logging and use of a crash recovery algorithm. Similar crash recovery algorithms can also be used in a main memory-based DBMS. Due to the volatility of main memory data storage (e.g. DRAM) that loses all data when the power is interrupted or switched off, a failure of a machine or operating system can potentially cause a complete loss of all data. Therefore, a typical approach involves logs of changes occurring as a result of a transaction being stored to non-volatile storage (e.g. hard disk drives, solid state drives, optical drives, etc.) in the order in which they were created. This approach is referred to as transaction logging. If a database server is taken out of service due to an unscheduled event, log entries read from the non-volatile storage are replayed into the database to support creation of a consistent state of the database.